STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/INTERNET/SITES/RAND/ALL96.LZH/t0113/text0006.txt

Text File | 1996-03-07 | 9.0 KB | 177 lines

> This is mainly a reply to Magnus' comments to my comments :)

:-)

> In retrospect, after reading your reply, I guess I have to agree that we
> are both right. There will always be _some_ people on an open mailing list
> like this that will be unable to contribute with much of use, but I guess
> I was a bit too pessimistic when it comes to the percentage of people who
> fall into that category.

I hope so. :-)

> But still, the number of people on the list, we have learned, is about 40,
> and the number of people who regularly post anything (Including me, since
> I believe I'll try to make myself a little useful from now on) is not
> really that high (I'd guess about 15 regulars).

That's probably correct. 15 regular contributers is better than nothing and
maybe 10% of what we say could be used in the future. I know we are up in the
blue sometimes, but I don't see that as a bad thing, I think it's good that
we do have ideas no matter how crazy they are.

> > I just want to get some response so that the list doesn't die. I know it's a
> > fine line to walk, but I hope I havn't stepped on to many toas. I would
> > hate to see this project slowly die as it's of great interest to the rest of
> > the atari (falcon) world.
>
> That I must absolutely agree on! This project might have a great impact on
> several aspects of the great international society of Falcon (OR Atari)
> owners. First of all, it shows that there's still a keen interest in
> making good programs (Not solely games) for our beloved platform. Second,
> the co-operation of so many people from different countries proved to me
> that that Atari scene still is bright and active, and that people are
> willing to help each other out when they need aid. These two main aspects
> together show that the Atari will not be dead for quite some time yet, at
> least not in our hearts, and that might persuade some people who have
> doubts about the Falcon to buy one, or to keep one if they intended to
> sell it.

Yes. :-) Think if something like this would have happend 2-3 years ago!

> > And look! You did write some very interesting things now and I
> > havn't seen your name before. That shows that there is some programmers out
> > there having good ideas.
>
> True, true. I mean, it's not very surprising that you haven't seen my name
> before, since I have mainly been quite anonymous in the Atari society
> since I finally made it onto the net about eighteen months ago. I believe
> there are many like me, too.

Ys, I havn't been in here to long either. When you have started to write
some messages, you can't stop.... it's that first message that is the hardest.

> > I do also suspect that we have got several good
> > demo coders with us that might want to help with some cool things. :-)
>
> Again, true. The problem is just to make them aware of this project, and
> persuade them to lend a hand. (I was about to write "lend us a hand", but
> I suppose it'd be wrong of me to use the word "us" in that context ;-) The
> reasons why we should ask demo coders to look into the project is quite
> simple: They have the experience that so many of us lack. The 3D-routs of
> EKO are just about the best I've ever seen, and getting an experienced
> demo-coder to hand us a quick routine for sprites should be a piece of
> cake. Provided the request comes from someone who really knows them. And
> I, unfortunately, don't.

Same goes for me. :-( The only one I "know" is Doug and he is in here. :-)
We might get some more democoders from france joining us shortly as there
is an french atari mag that will write about Bad Mood.

> > Sadly, I will probably fall into that category that isn't of any programing use,
> > since I only program in C. :-|
>
> Hmmm... Someone asked if the networking modules could be programmed in C,
> and I believe they could. Choosing GCC would undoubtedly be the best,
> though the GEM environment of Pure C makes coding easier. (Perhaps a first
> try in Pure C and then porting would be the way to go...)

I'm that someone. Can't we use Lattice C..... ;-)

> To get a bit technical here, passing parameters from the Bad Mood main
> program to a resident networking module is not hard - if a parameter
> buffer is initialized prior to the loading of the networking module, and
> the address of that buffer is passed to the module as it is loaded, it
> would be easy (Probably) to make this following idea work...

Sounds okey to me, but I have no experince of thing s like this.

> Consider a resident networking module that attaches itself to an interrupt
> (eg. VBL) and does two things:
> 1: It listens to whatever port it is initialized to listen to, and if
>    something is coming in, it somehow tells the host program (Bad Mood) that
>    something has come in, and transfers it to an incoming buffer before
>    passing it on to the next machine in the network (Remember that in case
>    of a Midi network, multiple Falcons can be networked in a circle, and
>    since messages can only be sent one way they must pass through all the
>    machines until it gets back to the originating machine, which will
>    then NOT send it out again ;-)
> 2: It waits for the host program to request the transmission of a package to
>    the other machines in the network, and when requested to do so, sends it
>    out.
> This fairly simple idea can be made possible the easy way. The parameter
> buffer that can be used for communication between module and host program
> could look like this ( Simple C structure ) :
> struct {
>   int incoming = 0 ;    /* Flag checked by host prog: !=0 => Incoming true */
>   int outgoing = 0 ;    /* Flag checked by module: !=0 => Outgoing true    */
>   int acknowledge = 0 ; /* Ready flag for comm. Module <==> host program   */
>   long *inbuffer ;      /* Pointer to the incoming buffer                  */
>   long *outbuffer ;     /* pointer to the outgoing buffer                  */
>   int buf_size ;        /* Could be a long, but not necessary              */
> } net_parameter ;
> I'm fairly certain most people on this list see where I'm heading. This
> structure is designed to make expansion easy. I'll give a more in-depth
> explanation of my idea for the code to anyone who asks for it.

This sounds good to me, but as I said I havn't done anything like this before
so I can't realy say anything. :-(

> And now about the protocol to be used:
>
> > Maybe you could think about that too? If I understand it right you need to
> > know what direction the players are heading and there they are and if
> > the fire or not. The collision detection will be calculated on each machine.
> > You will also need to know if someone have activated any switches. Maybe this
> > is to simple, but something like that.
>
> It would be easy to transmit raw binary data between the machines, so an
> as simple as possible protocol would be the best choice. (As optimized as
> possible, either concerning speed or size) But in addition to just passing
> the data, a few more things need to be transferred: To avoid having a
> package being sent in circles again and again we need to know which
> machine originally sent it. Since the best idea would be to let each
> machine's networking module be oblivious to the number of opponents (Only
> the bad Mood program itself needs to know that. I have already thought if
> how to best organize the best initial initialization of the network...

Ofcourse you have to know who sent it. Each player will have an id number that
the other have to check. One machine have to me master and deceid the id
for each machine. Just start to count at the first one and continue until you
have come back. Hmm.. didn't I do a controller like this in VHDl...

> > Why not contact Doug your self? I know he and Dave Murphy have discussed
> > some crazy ideas about networking. He would also know which data need
> > to be transferd to make it work.
>
> I suppose it's now pretty clear that I'm interested in helping out on the
> networking modules, so if anyone have any ideas to comapre to mine, please
> send me a note. Right now, however, I'm rather soon on my way to class (Oh
> this darn college) so I don't think I'll have the time to write another
> e-mail.

Maybe you could take care about this network part? It sounds like you have
some good ideas and experience. You can maybe start to think about how it
could be done and those who is interested could help you. I think doing the
first version in C could be a good idea and maybe later rewrite it in
assembler when it's stable?

> > > Anybody have any comments on this? Flames can be directed to me,
> > > personally (I have some negative experiences from writing to mailing lists
> > > earlier... Ouch, was I scorched!)
> > I don't think you will get any flames. :-)
> > I have also got burned sometimes. That is a part of the game... ;-)
>
> True yet again - I forgot I was on an Atari mailing list! Not many of us
> ever write flames to each other! 8-)

No. :-)

> Well, that's it for this mail. I see one mor ething I'd like to comment
> on, but I'll take that in another short posting...

Okey.

//Magnus Kollberg